tokfandomcom-20200215-history
Wine
Wine ( for Wine Is Not an ) is a that aims to allow s ( and s) developed for to run on s. Wine also provides a , known as Winelib, against which developers can Windows applications to help them to Unix-like systems. Wine provides its Windows which translates Windows s into -compliant s, recreating the of Windows systems, and providing alternative implementations of Windows , system services through wineserver and various other components (such as , the , and ). Wine is predominantly written using reverse-engineering, to avoid issues. In a 2007 survey by desktoplinux.com of 38,500 Linux desktop users, 31.5% of respondents reported using Wine to run Windows applications. This plurality was larger than all programs combined, as well as larger than the 27.9% who reported not running Windows applications. Design The goal of Wine is to implement the s fully or partially that are required by programs that the users of Wine wish to run on top of a Unix-like system. Basic architecture The programming interfaces of the Microsoft Windows family of OSes consist largely of (DLLs). These contain a huge number of wrapper sub-routines for the system calls of the kernel, the NTOS kernel-mode program (ntoskrnl.exe). A typical Windows program calls some Windows DLLs, which in turn calls user-mode gdi/user32 libraries, which in turn uses the kernel32.dll (win32 subsystem) responsible for dealing with the kernel through system calls. The system-call layer is considered private to Microsoft programmers as documentation is not publicly available, and published interfaces all rely on subsystems running on top of the kernel. Besides these, there are a number of programming interfaces implemented as services that run as separate processes. Applications communicate with user-mode services through RPCs. Wine implements the Windows (ABI) entirely in , rather than as a . Wine mostly mirrors the hierarchy, with services normally provided by the kernel in Windows instead provided by a known as the wineserver, whose task is to implement basic Windows functionality, as well as integration with the , and translation of into native Windows exceptions. Although Wineserver implements some aspects of the , it is not possible to use native Windows drivers with it, due to Wine's underlying architecture. This prevents certain applications and games from working, for example those using StarForce copy-protection which requires to be installed. Libraries and applications Wine allows for loading both Windows DLLs and Unix s for its Windows programs. Its builtin implementation of the most basic , namely , , , , uses the shared object method because they must use functions in the host operating system as well. Higher-level libraries, such as WineD3D, are free to use the DLL format. In many cases users can choose to load a DLL from Windows instead of the one implemented by wine. Doing so can provide functionalities not yet implemented by wine, but may also cause malfunctions if it relies on something else not present in wine. Wine tracks its state of implementation through automated done at every git commit. Graphics and gaming While most office software does not make use of complex GPU-accelerated graphics APIs, computer games do. To run these games properly, Wine would have to forward the drawing instructions to the host OS, and even translate them to something the host can understand. is a collection of Microsoft APIs for rendering, audio and input. As of 2019, Wine 4.0 contains a DirectX 12 implementation for , and DirectX 11.2 for OpenGL. Wine 4.0 also allows Wine to run Vulkan applications by handing draw commands to the host OS, or in the case of macOS, by translating them into the by . ; XAudio : , Wine 4.3 uses the library to implement the audio API. ; XInput and Raw Input : Wine, since 4.0 (2019), supports s through its builtin implementations of these libraries. They are built as Unix shared objects as they need to access the controller interfaces of the underlying OS, specifically through . ; Direct2D : Wine 4.0 supports Direct2D 1.2. Direct3D Much of Wine's DirectX effort goes into building WineD3D, a translation layer from Direct3D and API calls into . As of 2019, this component supports up to DirectX 11. As of , wine is good enough to run with D3D11. Besides being used in Wine, WineD3D DLLs are also useful in the Windows Operating System itself, allowing for older graphic cards to run games using newer DirectX versions and for old DDraw-based games to render correctly. Some work is ongoing to move the Direct3D backend to Vulkan API. Direct3D 12 support in 4.0 is provided by a "vkd3d" subproject, and WineD3D has in 2019 been experimentally ported to use the Vulkan API. Wine, when patched, can alternatively run Direct3D 9 without translation via the a State Tracker for DX9. The Gallium3D layer allows for direct pass-through of drawing commands. User interface Wine is usually invoked from the command-line interpreter: wine program.exe. winecfg There is the utility winecfg that starts a graphical user interface with controls for adjusting basic options. It is a GUI configuration utility included with Wine. Winecfg makes configuring Wine easier by making it unnecessary to edit the registry directly, although, if needed, this can be done with the included registry editor (similar to Windows ). Third-party applications }} Some applications require more tweaking than simply installing the application in order to work properly, such as manually configuring Wine to use certain Windows DLLs. The Wine project does not integrate such s into the Wine codebase, instead preferring to focus solely on improving Wine's implementation of the Windows API. While this approach focuses Wine development on long-term compatibility, it makes it difficult for users to run applications that require workarounds. Consequently, many third-party applications have been created to ease the use of those applications that don't work out of the box within Wine itself. The Wine wiki maintains a page of current and obsolete third-party applications. * Winetricks is a to install some basic components (typically Microsoft DLLs and fonts) and tweak settings required for some applications to run correctly under Wine. It can fully automate the install of a number of apps and games, including applying any needed workarounds. Winetricks has a . The Wine project will accept bug reports for users of Winetricks, unlike most third-party applications. It is maintained by Wine developer Austin English. * is an open Gui for advanced setup of Wine. * Wine-Doors is an application-management tool for the desktop which adds functionality to Wine. Wine-Doors is an alternative to WineTools which aims to improve upon WineTools' features and extend on the original idea with a more modern design approach. * is a utility to install all versions of Internet Explorer, including versions 4 to 6 and version 7 (in beta). * Wineskin is a utility to manage Wine engine versions and create wrappers for . * is an application to ease the installation of Windows applications (primarily games). There is also a corresponding Macintosh version called . * Lutris is an open source application to easily install Windows games on Linux. * is a proprietary Wine GUI configuration manager that runs winelib applications. It also supports installation of third-party utilities, installation of applications and games, and the ability to use custom configurations. Bordeaux currently runs on Linux, FreeBSD, PC-BSD, Solaris, OpenSolaris, , and macOS computers. Functionality The developers of the portions of Wine have continued to implement new features such as to increase game support. Wine can also use native DLLs directly, thus increasing functionality, but then a license for Windows is needed unless the DLLs were distributed with the application itself. Wine also includes its own open-source implementations of several Windows programs, such as , , , , and . The Wine Application Database (AppDB) is a community-maintained on-line database about which Windows programs works with Wine and how well they work. Backward compatibility Wine ensures good with legacy Windows applications, including those written for . Wine can mimic different Windows versions required for some programs, going as far back as Windows version 2.0. However, Windows 1.x and Windows 2.x support was removed from Wine development version 1.3.12. If DOSBox is installed on the system (see below on ), Wine development version 1.3.12 and later nevertheless show the "Windows 2.0" option for the Windows version to mimic, but Wine still won't run most Windows 2.0 programs because MS-DOS and Windows functions are not currently integrated. Backward compatibility in Wine is superior to that of Windows, as newer versions of Windows can force users to upgrade legacy Windows applications. In many cases, Wine can offer better legacy support than newer versions of Windows with "Compatibility Mode". Wine can run Windows programs on a 64-bit operating system, which uses an (64-bit) CPU, a functionality not found in 64-bit versions of Microsoft Windows. Wine partially supports Windows s, and the user can choose which backend to use to manage the console (choices include raw streams, , and ). When using the raw streams or curses backends, Windows applications will run in a Unix terminal. 64-bit applications Preliminary support for Windows applications was added to Wine 1.1.10, in December 2008. , the support is considered stable. The two versions of wine are built separately, and as a result only building wine64 produces an environment only capable of running x86-64 applications. , Wine has stable support for a build, which allows both 32-bit and 64-bit Windows applications to run inside the same Wine instance. To perform such a build, one must first build the 64-bit version, and then build the 32-bit version referencing the 64-bit version. Just like Microsoft's WoW64, the 32-bit build process will add parts necessary for handling 32-bit programs to the 64-bit build. This functionality is seen from at least 2010. MS-DOS Early versions of Microsoft Windows run on top of and Windows programs may depend on MS-DOS programs being runnable. Wine does not have good support for MS-DOS, but starting with development version 1.3.12, Wine tries running MS-DOS programs in if DOSBox is available on the system. However, due to a bug, current versions of Wine incorrectly identify Windows 1.x and Windows 2.x programs as MS-DOS programs, attempting to run them in DOSBox (which does not work). Winelib Wine provides Winelib, which allows its shared-object implementations of the Windows API to be used as actual libraries for a Unix program. This allows for Windows code to be built into native Unix executables. Since October 2010, Winelib also works on the platform. Non-x86 architectures Support for Solaris was dropped in version 1.5.26. ARM, Windows CE, and Windows RT Wine provides some support for (as well as ARM64/AArch64) processors and the Windows flavors that run on it. , Wine can run ARM/Win32 applications intended for unlocked devices (but not Windows RT programs). support (either x86 or ARM) is missing, but an unofficial, proof-of-concept version called WineCE allows for some support. 4 Wine for Android running on Android}} On 3 February 2013 at the FOSDEM talk in Brussels, demonstrated an early demo of Wine running on Google's operating system. Experimental builds of WINE for Android (x86 and ARM) were released in late 2017. It has been routinely updated by the official developers ever since. The default builds does not implement cross-architecture emulation via , and as a result ARM versions will only run ARM applications that use the Win32 API. Microsoft applications Wine, by default, uses specialized Windows builds of and to substitute for Microsoft's and . Wine has built-in implementations of and . It is possible to download and run Microsoft's installers for those programs through winetricks or manually. Wine is not known to have good support for most versions of Internet Explorer. Of all the reasonably recent versions, Internet Explorer 8 for Windows XP is the only version that reports a usable rating on Wine's AppDB, out-of-the-box. Winetricks offer auto-installation for Internet Explorer 6 through 8, so these versions can be reasonably expected to work with its built-in workarounds. An alternative for installing Internet Explorer directly is to use the now-defunct . It is not compatible with the latest versions of Wine, and the development of IEs4Linux is inactive. Microsoft has not made public statements about Wine. However, the software will block updates to Microsoft applications running in Wine. On 16 February 2005, Ivan Leo Puoti discovered that Microsoft had started checking the for the Wine configuration key and would block the Windows Update for any component. As Puoti noted: "It's also the first time Microsoft acknowledges the existence of Wine." References Category:Computer science